

For example, the immutable class \code{String} contains
        a lazily-initialized field for caching the hash-code,
        i.e., field \code{hash} is assigned inside the \code{hashCode}
        method and not in the constructor.\footnote{A perverse programmer could make
      the \code{hashCode} method return a different value on every invocation.
      Method idempotency (repeated calls return the same value)
      is different than state immutability, though an idempotency analysis
      could be built on top of OIGJ\@.}



%I know you like rewriting paragraphs to save space.  (I recommend writing
%for clarity first, though, because that feels like peephole optimization.)
%So, here is another trick I am sure you will like, that can avoid the need
%for rewriting.
%
%If a paragraph has only a word or two on its last line, try adding
%\looseness=-1 to the end of it. If possible TeX will reduce/shorten the
%length of the paragraph by a line. This won't always work because there is
%a limit to how close TeX will move words.


%\textbf{Covariant subtyping} for readonly references is supported by OIGJ\@.
%Variant parametric types~\cite{1152650} attaches a variance annotation to
%    a type argument,
%    e.g., \code{Vector\hgn{+Number}} (for covariant typing) or
%    \code{Vector\hgn{-Number}} (for contravariant typing).
%Java's wildcards and existential types~\cite{CameronDE2008,OstlundWC2008}
%    can express similar variance, e.g.,
%    \code{Vector\hgn{?~extends Number}} (for covariant typing) or
%    \code{Vector\hgn{?~super Number}} (for contravariant typing).
%Variant parametric types and wildcards restrict method calls based on
%    \emph{method signature}.
%On the other hand, the restriction on method calls in OIGJ is based on
%    user-chosen \emph{semantics}
%    (whether the method is readonly or not).


%When we tried to claim why OIGJ is better than GUT:
%
%\subsection{List Iterators and Ownership}
%List iterators pose a challenge to ownership because
%    they require a direct pointer to the list's privately owned entries,
%    thus breaking the ownership property.
%Various solutions have been proposed to this problem:
%\begin{itemize}
%  \item Redesign the code, i.e., implement iterators without violating
%    ownership,
%    e.g., by using internal iterators or
%    magic-cookies~\cite{Noble2000}.
%  \item Assign different access rights for stack and field
%    variables~\cite{ClarkeD2002},
%    i.e., you can iterate the list using a stack variable, but you cannot store
%    that variable in a field.
%  \item Assign special access rights to inner classes.
%    Boyapati~\cite{BoyapatiLS2003} allowed an inner instance to have different
%        owner from their outer instance,
%        but the inner instance could still access the outer instance's privately
%        owned objects.
%
%    OIGJ enforces %, in its \textbf{Inner class rule},
%        that an inner instance has the same owner has its outer instance.
%    Therefore, a mutable iterator has the same owner as its container,
%        but a readonly iterator may be freely shared.
%
%  \item Generic Universe Types (GUT)~\cite{DietlDM2007}
%    assigns special rights using the keyword \code{peer} that requires a
%    mechanism
%    called \emph{viewpoint adaptation}.
%    \Ref{Figure}{GUT-LinkedList1} and \Ref{Figure}{GUT-LinkedList2} show two
%        possible implementations of
%        list iterators in GUT.
%    The first implementation in \Ref{Figure}{GUT-LinkedList1} uses a single
%        iterator class \code{ListItr},
%        storing readonly references to the list (line~\ref{GUT:list})
%        and the current iterator position (line~\ref{GUT:next}).
%    The mutable \code{remove} method must cast at runtime both references to
%        \code{peer} (line~\ref{GUT:cast})
%        to ensure that the given entry belongs to the receiver list.
%    The second implementation in \Ref{Figure}{GUT-LinkedList2} avoids the cast
%        by duplicating the iterator code
%        in two classes, \code{ReadOnlyListIter} and \code{MutableListIter},
%        for readonly and mutable iteration (iteration that can \code{remove}
%        elements).
%    The second design requires two \code{iterator()} methods: one that returns
%        a \code{readonly} iterator,
%        and a second that returns a \code{peer} iterator.
%
%\end{itemize}
%
%\begin{figure}
%\begin{algorithmic}[1]
%\STATE \code{class ListIter implements Iterator \lb} \label{GUT:start}
%\STATE \code{~~readonly List l;} \label{GUT:list}
%\STATE \code{~~readonly Entry current;} \label{GUT:next}
%\STATE \code{~~public void remove() \lb}
%\STATE \code{~~~~((peer List)l).remove((peer Entry)current);}\label{GUT:cast}
%\STATE \code{~~\rb}
%\STATE \code{\rb} \label{GUT:end}
%\end{algorithmic}
%\caption{Implementation 1 of list iterators in GUT (using a cast).}
%\label{Figure:GUT-LinkedList1}
%\end{figure}
%
%\begin{figure}
%\begin{algorithmic}[1]
%\STATE \code{class ReadOnlyListIter implements Iterator \lb}\label{GUT:ROLI:s}
%\STATE \code{~~readonly List l;}
%\STATE \code{~~readonly Entry current;}
%\STATE \code{\rb} \label{GUT:ReadOnlyListIter:end}
%\STATE \code{class MutableListIter implements Iterator \lb}\label{GUT:MLI:s}
%\STATE \code{~~peer List l;}
%\STATE \code{~~peer Entry current;}
%\STATE \code{~~public void remove() \lb~\ldots~\rb}
%\STATE \code{\rb} \label{GUT:MutableListIter:end}
%\end{algorithmic}
%\caption{Implementation 2 of list iterators in GUT
%(duplicating the iterator code).}
%\label{Figure:GUT-LinkedList2}
%\end{figure}
